Electronics devices and capabilities have grown extremely common in daily life. Along with personal computers in the home, many individuals carry more than one productivity tool for various and sundry purposes. Most personal productivity electronic devices include some form of non-volatile memory. Cell phones utilize non-volatile memory in order to store and retain user programmed phone numbers and configurations when the power is turned off. PCMCIA cards utilize non-volatile memory to store and retain information even when the card is removed from its slot in the computer. Many other common electronic devices also benefit from the long-term storage capability of non-volatile memory in un-powered assemblies.
Non-volatile memory manufacturers that sell to the electronic equipment manufacturers require testers to exercise and verify the proper operation of the memories that they produce. Due to the volume of non-volatile memories that are manufactured and sold at consistently low prices, it is very important to minimize the time it takes to test a single part. Purchasers of non-volatile memories require memory manufacturers to provide high shipment yields because of the cost savings associated with the practice of incorporating the memory devices into more expensive assemblies with minimal or no testing. Accordingly, the memory testing process must be sufficiently efficient to identify a large percentage of non-conforming parts and preferably all non-conforming parts in a single test process.
As non-volatile memories become larger, denser and more complex, the testers must be able to handle the increased size and complexity without significantly increasing the time it takes to test them. Memory testers frequently run continuously, and test time is considered a major factor in the cost of the final part. As memories evolve and improve, the tester must be able to easily accommodate the changes made to the device. Another issue specific to testing non-volatile memories is that repeated writes to cells of the memories can degrade the overall lifetime performance of the part. Non-volatile memory manufacturers have responded to many of the testing issues by building special test modes into the memory devices. These test modes are not used at all by the purchaser of the memory, but may be accessed by the manufacturer to test all or significant portions of the memories in as little time as possible and as efficiently as possible. Some non-volatile memories are also capable of being repaired during the test process. The tester, therefore, should be able to identify: a need for repair; a location of the repair; the type of repair needed; and, must then be able to perform the appropriate repair. Such a repair process requires a tester that is able to detect and isolate a specific nonconforming portion of the memory. In order to take full advantage of the special test modes as well as the repair functions, it is beneficial for a tester to be able to execute a test program that supports conditional branching based upon an expected response from the device.
From a conceptual perspective, the process of testing memories is an algorithmic process. As an example, typical tests include sequentially incrementing or decrementing memory addresses while writing 0""s and 1""s into the memory cells. It is customary to refer to a collection of 1""s and 0""s being written or read during a memory cycle as a xe2x80x9cvectorxe2x80x9d, while the term xe2x80x9cpatternxe2x80x9d refers to a sequence of vectors. It is conventional for tests to include writing patterns into the memory space such as checkerboards, walking 1""s and butterfly patterns. A test developer can more easily and efficiently generate a program to create these patterns with the aid of algorithmic constructs. A test pattern that is algorithmically coherent is also easier to debug and facilitates the use of logical methods to isolate portions of the pattern that do not perform as expected. A test pattern that is generated algorithmically using instructions and commands that are repeated in programming loops consumes less space in tester memory. Accordingly, it is desirable to have algorithmic test pattern generation capability in a memory tester.
Precise signal edge placement and detection is also a consideration in the effectiveness of a non-volatile memory tester. In order to capture parts that are generally conforming at a median while not conforming within the specified margins, a non-volatile memory tester must be able to precisely place each signal edge relative in time to another signal edge. It is also important to be able to precisely measure at which point in time a signal edge is received. Accordingly, a non-volatile memory tester should have sufficient flexibility and control of the timing and placement of stimuli and responses from the Device Under Test (memory).
Memory testers are said to generate xe2x80x9ctransmitxe2x80x9d vectors that are applied (stimulus) to the DUT (Device Under Test), and xe2x80x9creceivexe2x80x9d vectors that are expected in return (response). The algorithmic logic that generates these vectors can generally do so without troubling itself about how a particular bit in a vector is to get to or from a particular signal pad in the DUT, as the memory tester contains mapping arrangements to route signals to and from pins.
Memory testers have interior test memory that is used to facilitate the test process. This interior test memory may be used for several purposes, among which are storing transmit vectors ahead of time, as opposed to generating them in real time, storing receive vectors, and storing a variety of error indications and other information concerning DUT behavior obtained during testing. (There are also housekeeping purposes internal to the operation of the memory tester that use SRAM and that may appear to fall within the purview of the phrase xe2x80x9cinterior memory.xe2x80x9d These are private to the internal operation of the tester, tend to not be visible at the algorithmic level, and are comparable to internal control registers. That memory is described as xe2x80x9cinterior control memory,xe2x80x9d and is excluded from what is meant herein by the term xe2x80x9cinterior test memory,xe2x80x9d which we use to describe memory used to store bit patterns directly related to the stimulus of, and response from, the DUT.) It is easy to appreciate that this interior test memory needs to operate at least as fast as the tests being performed; a very common paradigm is for the interior test memory (or some portion thereof) to be addressed by the same address (or some derivative thereof) as is applied to the DUT. What is then stored at that addressed location in interior test memory is something indicative of DUT behavior during a test operation performed on the DUT at that address. Algorithmic considerations within the test program may mean that the sequence of addresses associated with consecutive transmit vectors can be arbitrary. Thus, the interior memory needs to have the dual attributes of high speed and random addressability. SRAM comes to mind immediately as being fast, easy to control and tolerant of totally random addressing. Indeed, conventional memory testers have used SRAM as their interior test memory.
Unfortunately, SRAM is quite expensive, and this has limited the amount of interior test memory with which memory testers have had to work. The result is limits on memory tester functionality that are imposed by a shortage of memory. DRAM is significantly less expensive, but cannot tolerate random addressing and still perform at high speed.
DRAM can replace SRAM as the interior test memory in a memory tester. As briefly described in a simplified overview below, the problem of increasing the speed of DRAM operation for use as interior test memory can be solved by increasing the amount of DRAM used, in place of increasing its speed. Numbers of identical Banks of DRAM are treated as Groups. A combination of interleaving signals for different Banks of memory in a Group thereof and multiplexing between those Groups of Banks slows the memory traffic for any one Bank down to a rate that can be handled by the Bank. (For the reader""s convenience, we include a very abbreviated summary of this technique here, since much of its architectural aspects and associated terminology are useful in the explanation of the inventive subject matter that follows.)
A three-way multiplexing between three Groups of four Banks each, combined with a flexible four-fold interleaving scheme for signal traffic to a Group produces an increase in operating speed approaching a factor of twelve, while requiring only three memory busses. A round robin strategy for choosing the next Group for the multiplexer is simple and assures that the interleaving mechanism for each Group has the time it needs to complete its most recently assigned task. All interleaved accesses within a Group are performed upon a next Bank (within that Group), also selected by a simple round robin selection. In this configuration, each of the twelve Banks represents a duplicate instance of the entire available address space, and any individual write cycle might end up accessing any one of the twelve Banks. An implication is that, at the conclusion of testing, all twelve Banks must be investigated to learn what failures happened during testing of the DUT, since the history of any address or collection of addresses of interest will be spread out across all twelve Banks. A particular channel is thus represented by twelve bits (one bit from each Bank and whose bit position within the word for that Bank is determined by the channel).
It would be, however, awkward to have to (manually, as it were) individually consult all twelve Banks to discover failure information, so a utility mechanism has been provided to automatically xe2x80x9ccomposexe2x80x9d (merge) results of all twelve Banks during a read cycle at an address into a unified result that can be stored in one or all twelve Banks. This allows composed data to later be read at full speed. Full speed in one embodiment is a 100 MHZ rate for randomly addressed memory transactions.
If 33 MHZ is fast enough, then random access can be supported with just the interleaving and no multiplexing, in which case the composition mechanism and the memory addressing scheme are suitably adjusted. The addressing scheme changes to include extra Group selection bits that allow the depth of the memory to be three times deeper than for random 100 MHZ operation. These two modes of operation are called R100 and R33, respectively. There is also an L100 mode of 100 MHZ operation to single Banks that relies on well behaved addresses being sent to the DRAM (an absolute minimum of row address changes).
At the top level of interior test memory organization there are four Memory Sets, each having its own separate and independent address space and performing requested memory transactions. Two are of DRAM as described above, and two are of SRAM. Each Memory Set has its own controller to which memory transactions are directed. As to externally visible operational capabilities, all four Memory Sets are essentially identical. They differ only in their size of memory space and how they are internally implemented: The SRAM Memory Sets do not employ multiplexing and interleaving, since they are fast enough to begin with. Despite their independence, Memory Sets of the same type (of SRAM or of DRAM) may be xe2x80x9cstacked,xe2x80x9d which is to say treated a one larger address space. This is done at the level of control above the Memory Sets themselves, in the algorithmic generation of the addresses and the decision as to which Memory Set to actually send a memory transaction. It is not as automatic as the way in which the Memory Sets and their controllers can stack groups to triple the address space as between the R100 and R33 modes of operation. For each of the Memory Set controllers, it has no clue that there even is such a thing as another Memory Set with another controller.
Thus it is that the interior test memory of the tester is divided into four Memory Sets, two of which are xe2x80x9cinternalxe2x80x9d SRAM""s and two of which are xe2x80x9cexternalxe2x80x9d DRAM""s. To be sure, all this memory is physically inside the memory tester; the terms xe2x80x9cinternalxe2x80x9d and xe2x80x9cexternalxe2x80x9d have more to do with a level of integration. The SRAM""s are integral parts of a VLSI (Very Large Scale Integration) circuit associated with the tester""s central functional circuitry, while the DRAM""s are individual packaged parts mounted adjacent the VLSI stuff. The amount of SRAM is fairly small, (say, around a megabit per Memory Set) while the amount of DRAM is substantial and selectable (say, in the range of 128 to 1024 megabits per Memory Set). The SRAM Memory Sets are always present, and may be used for any suitable purpose, such as storing the expected content of a DUT that is a ROM (Read Only Memory). The DRAM Memory Sets are actually optional, and are typically used for creating a trace for subsequent analysis leading to repair, although there are also other uses. The tester does not enforce a distinction between the SRAM and DRAM Memory Sets, as to different purposes for which they may be used. Those distinctions arise mostly as a matter of size. The SRAM Memory Sets are small, while the DRAM Memory Sets are potentially huge. The person or persons creating the test programming make the decisions concerning how the various Memory Sets are to be used.
We mentioned earlier that an algorithmic capability was desirable in developing and maintaining the test programs that are to be executed with the memory tester. In addition to the complexity that programmability allows (loops nested within loops, branching on test results), there are various special operational capabilities designed into it to facilitate both the automated testing of non-volatile memories in general, as well as of non-volatile memories that have certain peculiar properties. The import of all this is that there can be a corresponding complexity imparted to the development and maintenance activities for the test programs. In short, it is common for a test program to be a complicated mechanism unto itself.
Consider, then, the situation of a person developing a test program. It will not be uncommon for initial versions to fail to perform as expected; they do things they are not supposed to do and they don""t do things that they are supposed to. There are times when studying the code does not help (suppose that it is as correct as current understanding permits), and the most appropriate tool for finding out what is going on is an oscillographic trace of voltage waveforms: a source of additional data is needed to advance the process of understanding what is happening, or to verify a theory, etc. Unfortunately, it is not a practical matter to simply approach the test head and attach a probe or two for your favorite oscilloscope. Even if one could identify the actual physical locations where they would be attached (possible in principle, but often very difficult in practice), there is usually not enough room to do it, nor is that physical structure strong enough to support a probe and its cable. There is also the question of electrical loading or other disturbances to the desired measurements. And even if all those issues were overcome, there is still the problem of how to trigger the xe2x80x98scope so that the data captured pertains to the problem of interest.
As for the difficulty of connecting xe2x80x98scope probes, we will stand on what we have just said. As for the issue of the data the xe2x80x98scope is exposed to and what is captures, there is yet more background to appreciate before that issue can be properly understood. A useful point of departure here is a type of memory tester termed a xe2x80x9cvectorxe2x80x9d machine, such as may be found in the 83000 VLSI Test Series from Agilent Technologies.
A vector driven tester has an explicit list of stimulus vectors that it will apply, in order, to the DUT. It simply applies those and records what receive vectors occurred. It is very much an immediate-stimulus/immediate-response type of system: put this in, get that out. The nature of a vector machine and its DUT is such that the execution of the list can be interrupted at any time and execution re-started from some preselected convenient location in the list of transmit vectors. Similar to the algorithmically driven pattern oriented memory tester we will describe below, a vector tester has (for creation of receive vectors) variable sampling thresholds and variable sample timing offsets that are relative to some clock signal. A thing that is not present is an analog-to-digital converter that will digitize the analog voltage waveform of an associated channel. Nevertheless, the resources that are present can be used to reconstruct the voltage waveform on channels of interest during selected vectors. It is cumbersome, but it works (and there is no practical alternative). Here is how.
During ordinary (non-xe2x80x98scope mode) operation a particular pair of threshold values and a sample timing offset are selected, and data recorded for the sequence. The thresholds are VOH and VOL (Voltage Out High and Voltage Out Low), and are adjustable in steps of perhaps ten millivolts. The VOH threshold is met if, at the time specified by that channel""s sample timing offset, the channel voltage exceeds VOH, while the VOL threshold is met if the channel voltage is less than VOL. The names of the signals that represent these conditions are YVOH and YVOL, respectively. What is recorded for the associated channel in the receive vector is whether the channel voltage met each of the thresholds at the instant represented by the sample timing offset.
For the xe2x80x98scope mode, the basic idea is to find, for suitably spaced points in time along the waveform, what threshold values are on either side of the waveform at those points. To do this, a sequence of vectors containing the events of interest must be executed repeatedly. During such repeated execution the VOH voltage threshold is changed slightly between instances of repetition, and as the sequence is continually repeated and more and more data is stored. This might be continued until both extremes for the VOH threshold value have been used. For each vector in the sequence, the recorded receive results can be interpreted to create a contribution to an oscillographic trace. (Suppose that consecutive instances of YVOH were the same in value [TRUE], then at a certain instance the new value of YVOH changed [FALSE], after which consecutive values again became the same [both FALSE], but with a value opposite what they had when they were earlier the same, and then remained oppositely switched. That would indicate a stable voltage value for the channel at that point in time when the value changed from TRUE to FALSE, which point in time is identified by the (unchanging) sample timing offset in use for that progression of VOH values. The stable voltage value is somewhere between those consecutive instances of VOH for which YVOH changed value. There are also other cases in this well understood prior art technique, which, for the sake of brevity, we shall not mention.) For each vector, the afore-mentioned contribution will be for that sample timing offset only.
It will be appreciated that simply incrementing VOH from one extreme to another is not the only possible manner of finding a pair of VOH values that are suitably close together and for which the associated YVOH""s have opposite values. For example, there may be little point in sweeping over a five volt range for a three volt part. Next, given a starting point, it may be sufficient to cease incrementing once the transition has been found, or after a further few more increments confirm that the transition was indeed about there, even for a somewhat noisy signal. (A sampling that proceeds through a noisy transition can benefit from averaging.) Finally, one could even use a binary or other search strategy, including prediction, to try to minimize the number of repetitions needed to discover the relevant values of VOH that are associated with the desired transition in YVOH. This stuff is of interest to a user, because such strategies can significantly reduce the amount of time needed to produce the waveform(s) sought. Even so, it might still require minutes to complete the entire operation.
The next step is to repeat the entire operation with another sample timing offset. Eventually we will have created a complete description of the voltage behavior of the channel(s) during the vectors of interest, and can display it as a voltage waveform, just as in any digital oscilloscope. The vertical (voltage axis) resolution will be the step size for changing VOH, and the horizontal (time axis) resolution will be the step size for changing the sample timing offset (which can be as small as twenty picoseconds). This is a prior art technique that has been used in testers that are of the vector machine type. We""d like to use it in our algorithmically controlled pattern machine, but there are some serious difficulties.
Whereas a vector machine easily performs its trigger function by simply identifying one of the vectors in the explicit list thereof as when to trigger, it should be appreciated that in an algorithmically controlled machine xe2x80x9ctriggering the xe2x80x98scopexe2x80x9d (identifying the particular receive vectors to store data for) is non-trivial. As is usual in a digital environment, a simple analog trigger level with slope is almost certainly useless. Even detecting certain combinations of(simultaneous) signal values (a parallel word) is, by itself, often inadequate. Nor can one usually go to the code being executed to perform the test algorithm and say xe2x80x9cHere. Trigger when we execute this instruction word.xe2x80x9d There can be times when that will work, but often it will not, because it requires that there be in the code an instruction whose execution is uniquely associated with the failure. The algorithmic possibilities are often far too complicated, and the instruction xe2x80x9cat faultxe2x80x9d may appear in a loop and works perfectly well thousands or millions of times prior to the occurrence of the error.
We must also remember that the exact same series of events must occur many times (perhaps as many as the product of the number of different values of VOH with the number of different values for the timing offset) before there is sufficient captured data to allow the waveform(s) to be reconstructed as an oscillographic trace. Now assume that the test program includes a branch on an error flag (an error flag means the DUT""s response did not match some expectation). Error flags alter test program flow. But during repetitions for the xe2x80x98scope mode error flags are going to occur more frequently than not, and in every vector that is to contribute to the trace. Why? Because of the sweeping of the threshold and the sample timing offset. That sweeping is bound to create xe2x80x9cwrong answersxe2x80x9d that set the error flag and alter program flow, even when the DUT is not malfunctioning. It is almost a certainty that altered program flow would alter the waveforms in some corresponding way. But if the activity that is needed to reconstruct a trace from repeated identical instances of waveform activity alters the waveforms (as a result of altering program flow), then there will not be a stable waveform and no intelligible trace can be reconstructed. But branching on error flags within a test program is a powerful device, and one which we are unwilling to give up. That is, it should not be necessary to require test programs to be written in some restricted fashion to be usable with the xe2x80x98scope mode. Besides, we want a user of the memory tester to be able to apply the xe2x80x98scope mode to any pre-existing test programs without having to modify them to produce stable repetitions. Nor do we wish to perform source code modifications of test programs to facilitate or include trigger instructions. Instead, we want the memory tester itself to take care of these awkward issues on our behalf, in addition to reconstructing the trace from captured data obtained while sweeping the thresholds and the sample timing offset.
In addition, once a trigger specification mechanism is provided, we should like to be able to use the resulting trigger to force internal test program branching based on error flags to follow a particular path, regardless of the actual values of the associated error flags. For example, a test program may contain many branches that correspond to particular types of failures in the DUT. The programmer would like to verify that these various branches are all accessible, and that they perform as intended. The problem is how to invoke the various branches without having to edit the code, and also without having a collection of special DUT""s known to have exactly the right malfunctions to cause the desired exercising of the test program.
What to do?
A solution to the problem of providing a trigger signal to the xe2x80x98scope mode of a memory tester having an algorithmic pattern generator used in the execution of test programs having a substantial algorithmic content is to equip the algorithmic pattern generator with hardware to detect the occurrence of a trigger specification expressed in terms of existing hardware quantities used to operate the DUT, such as address and data, as well as incorporating the content of certain existing auxiliary registers that are provided to facilitate algorithmic behavior. This forms a raw hardware (breakpoint) trigger that can be further qualified according to what part of the test program is being executed. (The language presently used to create test programs does not allow the creation of abstract variables that exist only as values in an arbitrary memory location that is not one of the registers mentioned above. Accordingly, hardware masking and AND""ing performed on particular hardware registers in the algorithmic pattern generator is an adequate starting point for trigger generation.) The qualified breakpoint trigger can be delayed by zero or more DUT cycles before becoming a system trigger signal that can be used to trigger the xe2x80x98scope mode and to jam (force) an error flag to a selected value (so as to compel a particular path with the test program).
The test program itself is written in a language that resembles pseudo code, but with a constrained set of variables, as mentioned above. A compiler operates on this source code to produce executable instruction words that both control and respond to conditions in the rest of the hardware in the algorithmic pattern generator. A user interface aspect of the xe2x80x98scope mode process preferably executes in a separate environment, and the user interacts with that process to define a trigger specification. The xe2x80x98scope mode process sets up the masks and comparison mechanisms that recognize the raw trigger condition at the level of the hardware register values. It also informs the compiler as to which portions of the test program are to be considered as enabling the raw trigger specification. This is accomplished in the compiled code by providing in the executable instruction words for the algorithmic program generator a bit that means xe2x80x9cthe triggering function is presently enabled.xe2x80x9d The monitoring of values for abstract variables not closely tied to the test hardware and a genuine logic analyzer style sequential trigger might at some point be desirable, but are not necessary.
A solution to the problem of providing stable waveforms for the sweeping of the voltage thresholds and sample timing offset is for the memory tester to xe2x80x9cmemorizexe2x80x9d (i.e., record) the sequence of transmit vectors that are issued during an initial pass through the test program subsequent to the occurrence of the trigger, up to some suitable number, say, one hundred and twenty-eight. Let us call that sequence the xe2x80x9ctarget sequence.xe2x80x9d Once the target sequence is stored in memory (xe2x80x9cmemorizedxe2x80x9d), the xe2x80x98scope mode can extract the desired information by restarting the entire test program (because some initial conditions may need to be established) and letting it run exactly as before down to the trigger. But now when the trigger occurs further transmit vectors are issued from the memorized target sequence, rather than from the live algorithm, as it were, and a combination of VOH and the sample timing offset are switched into place. That combination constitutes one step along the acquisition sweep of their values, and is retained until the end of the memorized target sequence is reached. (An xe2x80x9cacquisition sweepxe2x80x9d is not to be confused with the xe2x80x9chorizontal sweepxe2x80x9d of an oscillographic presentation.) The corresponding sequence of receive vectors is automatically stored as they arrive. At the end of the target sequence the test program is re-started again (but with normal thresholds and sample timing offsets). In due course there is eventually another trigger, whereupon the memorized target sequence is again substituted for the live algorithm while the next combination in the step along the acquisition sweep is instituted until the end of the target sequence is again reached. As before, the receive vectors associated with that step in the acquisition sweep are automatically stored. This process is continued until the entire acquisition sweep has been performed, at which time the waveforms for the signals of interest during the target sequence can be created by suitable inspection of the corresponding collection of automatically stored receive vectors.
The technique described above is facilitated by equipping the memory tester with a FIFO (or other memory structure) for memorizing the target sequence and also with a control mechanism to oversee the memorizing and the subsequent switch to executing the memorized target sequence upon the occurrence of the trigger. Since the executable program word is much wider (two hundred eight bits wide) than the address needed to index through the program, it is the sequence of addresses for the instruction words in the target sequence that gets stored in the FIFO, rather than the instruction words themselves. After the addresses for the target sequence are stored in the FIFO and before the acquisition sweep begins, those addresses are used to fetch and store the corresponding actual sequence of instruction words. Any branching constructs in the copied target sequence are altered to point to the next word in the sequence (which will be the word that happened, anyway, during the initial capture of the target sequence). This executable target sequence is stored in a reserved portion of a Program SRAM that contains the instruction words that are the compiled test program. When subsequent system triggers occur test program execution is temporarily halted to institute the VOH and sample timing offset values for the next step in the acquisition sweep, and the program counter addressing the Program SRAM is set to the start of the reserved portion. Thus, once the next step in the acquisition sweep is set up, test program execution will resume with a repeat of the initially captured target sequence. The results (receive vectors) of each step in the acquisition sweep are temporarily stored (cached, as it were) in an ECR (Error Catch RAM). Such storage of receive vectors in an ECR is a normal operation, but which is usually conditioned upon certain errors of interest. Here we want it stored regardless of errors, and a simple mechanism is provided to accomplish that.
In addition, special registers aid in the rapid change of thresholds and sample timing from xe2x80x9cnormalxe2x80x9d to xe2x80x9csweptxe2x80x9d when the satisfied trigger condition is detected. The technique is further facilitated by arranging for the operating system that oversees the execution of the test program (and that administers the xe2x80x98scope mode) to have a private stash of memory that is used to unload the cached receive vectors from the ECR that were automatically stored during each step of the acquisition sweep over the target sequence. It is that stash of memory that the xe2x80x98scope mode then uses to accumulate and eventually create and display the waveforms for the signals of interest.
The problem of test program verification is assisted by using the trigger of the xe2x80x98scope mode (but probably sans the xe2x80x98scope mode of operation) to jam selected values for selected error flags into the environment of the executing test program. This forces the appearance of the associated type of error, even though it really didn""t happen. To be sure, the same error flags are apt to mean different things at different locations within the test program. To delay the occurrence of the error flag until a particular part of the program is reached is how the trigger is used. Just which error flags the trigger xe2x80x9csynthesizesxe2x80x9d is configurable. In this way the various error related branches of a complicated program can be exercised by xe2x80x9cwalkingxe2x80x9d the trigger through the program, even though the DUT in use is perfectly good.